구글에서 텍스트 에디터 프로젝트를 내 놓았습니다. xi-editor라는 프로젝트입니다. 지향점 몇 가지는 살펴볼만 합니다. 개발자가 느낄 수 있는 인사이트도 있습니다. 한번 살펴 볼까요?
2016/04/29 Editor’s choice
google/xi-editor
_xi-editor - A modern editor with a backend written in Rust._github.com
native! native!
Native UI. Cross-platform UI toolkits never look and feel quite right. The best technology for building a UI is the native framework of the platform. On Mac, that’s Cocoa.
기본적으로 Native UI로 컴파일하도록 합니다. 철학적인 컨셉으로 크로스 플랫폼 UI 툴킷은 이쁘지 않다는 것을 그 이유로 듭니다. 일견 동의가 되면서도 동의할 수 없는 부분이기는 합니다.
Background is Rust
Rust. The back-end needs to be extremely performant. In particular, it should use little more memory than the buffers being edited. That level of performance is possible in C++, but Rust offers a much more reliable, and in many ways, higher level programming platform.
성능! 을 위해서 UI는 코코아를 쓰고 background job (파일 및 버퍼등을 만지는)은 Rust를 이용한다고 하는구요. 성능상의 이유로 Rust는 이제 정말 각광 받는 언어가 되었나 봅니다. (Golang 어쩔…)
기타 특징
persistent rope data structure는 큰 포맷의 데이타를 처리하기 위해 사용되고, 비동기 형식으로 모든 operation을 만들어서 사용이 버벅! 거리는 일이 없게하는 것, 플러그인 관리를 파이프로 처리해서 scripting 하는 일을 줄이겠다, JSON으로 back-end,fron-end는 통신하는 등.
좋은 내용을 담고 있습니다. 많은 부분이 제가 주력으로 쓰는 아톰에디터에서 pain point라고 생각했던 부분인데 좋은 아키텍쳐를 표방하고 있습니다.
믿을 수 있을까?
draft.min.js
뭐랄까 언젠가 부터 구글의 오픈 소스는 어느 정도 의혹의 눈길을 받기 시작하는 거 같습니다. 정말 쓰일만한 걸 만드는 걸지, 아니면 저러다 drop 하는 건 아닐지. 자기들도 안쓰는 프레임워크(Angular)를 내 놓는 건 아닌지.
실행시켜 봤습니다.
성능에 대한 강조가 부심이 지나친 듯하여 min파일을 읽어보았습니다. 버벅 거리는 거는 마찬가지…입니다. (vi 가 아니면 다 똑같?) 하지만 응답 없음이 뜨지는 않는 군요.
아키텍처와 지향점은 굉장히 좋아고 생각합니다. min파일을 읽을때 대부분 에디터가 멈춤현상을 겪지만 그나마 빠르게 처리가 되는 것 같다는 부분에서 꽤나 인상적입니다. 이런 아키텍쳐를 다른 에디터들이 많이 가져가면 좋겠다는 생각이 듭니다.
syntax 강조 기능같은 에디터로서의 기초기능도 아직은 없으니 조금 더 기다려보면 좋은 에디터가 될 가능성도 무궁무진합니다.
By Keen Dev on April 28, 2016.
Exported from Medium on May 31, 2017.